home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / transcript_1108 / text0006.txt < prev    next >
Encoding:
Text File  |  1995-11-26  |  4.1 KB  |  98 lines
  1. > Who are the new participants ? Coders, do they code in assembler or in C ?
  2.  
  3. I recognized more than half of the email addresses, but if they want to
  4. introduce themselves, it's up to them.
  5.  
  6. > What are they doing ?
  7.  
  8. Very possibly nothing at all. The list in publically open, which means
  9. we may well have participants who only want to hear what's going on.
  10. Let's hope some of them are interested enough to help out a bit or at
  11. least take part in the discussions.
  12.  
  13. > For the conversion, I know lot's of parts of the code that I can improve,
  14. > we'll see at the end how far I can improve this ...
  15.  
  16. :-)
  17.  
  18. > I'm starting to look at the code that'll go into the DSP ( probably the 
  19. > BSP tree, I'm studying this...). If we could put it into the DSP, it would 
  20. > improve the code a lot, because of the big number of muls and divs.
  21.  
  22. Yes, just getting rid of all the clipping and rotation stuff would
  23. probably be helpful. Then there are those tables...
  24.  
  25. > For the algorithm question, I just thought of something, perharps stupid,
  26. > perharps not :-)
  27.  
  28. [some details about a bitmap of the level map deleted]
  29.  
  30. As Bertrand mentioned it's a rather good idea, but in contrast to him I
  31. see some problems with it. I'd very much like to be proven wrong, though.
  32.  
  33. I don't know if there are any limits to the coordinates that can be used
  34. on a DOOM map, but figures between 1000 and 2000 are common. That means
  35. that we need to keep a map of at least 2048x2048 in memory since I'm
  36. pretty sure we'll to represent at least the vertices exactly.
  37. With a single bit map that would be 512kbyte.
  38.  
  39. Now, how would that map be drawn?
  40. We really need every possible sector in there, which means that we'll
  41. have to go through the data structures and fill in all the sectors.
  42. But wait, we can't do that since some sectors are not always accessible,
  43. such as doors. The doors can of course be handled by repainting part of
  44. the map when they're opened/closed.
  45.  
  46. OK, assume we have a map. How do we use it?
  47. The map was drawn using some normal line routine, which means that the
  48. walls are (almost) never exactly drawn. Take a look at the following:
  49. (The player is the '+')
  50.  
  51. O******        O******
  52. OO*****        OO*****
  53. OOOO***  ->    OOO+***
  54. OO+OO**        OOOOO**
  55.  
  56. Both before and after the movement the player is on an 'O' which is
  57. supposed to mean open area in this case. In the latter case, however,
  58. the open space is only there because the line routine made a step.
  59. In reality that position is inside the wall.
  60. To make matters worse, the player's (and the monsters') position will most
  61. likely have to be stored as some kind of fixed point number. I don't think
  62. it's done like that right now since the current DVIEW is so slow anyway,
  63. but for fluid motion it will be needed.
  64.  
  65. If a position has a '*' (wall) close by, how do we find out if we're
  66. inside a wall or not? As far as I can see the only way to find out for
  67. sure (we _really_ don't want to draw from inside the wall) is to check
  68. against the line. But which line? Our bitmap does not say anything about
  69. that. And we're back to the original problem (IMO).
  70.  
  71. The bitmap could be used for a quick check that we're safe, but in most
  72. cases I think that could be done rather easily with the line coordinates
  73. as well.
  74.  
  75. By the way, can all trigger mechanisms and such be handled only by knowing
  76. which sector the player is in? Or is there ever a need to know which line
  77. was crossed?
  78.  
  79. > If I'm totally wrong, just tell me. :-)
  80.  
  81. You're certainly not totally wrong, but I doubt if it's possible to use
  82. your idea. I hope I'm mistaken, though.
  83.  
  84. > What about the square technic described by Bertrand ? What can we use it for ?
  85.  
  86. As Bertrand said, that's more or less the same thing but on a larger scale.
  87. For collision detection against objects I think that will work fine since
  88. the those are just sprites. There's no great problem if you don't get
  89. their positions exactly right.
  90.  
  91.  
  92. -- 
  93.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  94.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  95.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  96.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  97.  
  98.